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Abstract 

/ Intelligent control of the Space. Station will require the coordinated execution of computer programs across a substantial 
number of computing elements. It will be important to develop large subsets of these programs in the form of a single program 
which executes in a distributed fashion across a number of processors. In this pepei we describe a translation strategy for 
distributed execution of Ada programs in which library packages and subprograms may be distributed. A preliminary version of 
the translator » operational. Simple data objects (no records or arrays as yet), subprograms, and stati d tasks may be referenced 

I remotely. - \ / / 
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1 INTRODUCTION 

Intelligent control of the Space Station will require the coordinated execution of computer programs acmes a substantial 
numb er of computing elements. It will be important to develop Urge subsets of these programs in the form of a tingle program 
which executes in a distributed fashion acorss a number of processors. The single program approach to progra mm ing closely 
coordinated Ktions of multipie computers allows the advantages of language level software engineering developments, eg., abstract 
data types, separate compilation of specifications and implementations, and extensive compile time error checking to be fully 
realized acrom machine boundaries. In this paper we describe one approach to a tra n s l a t i on system for distributed execution of 
Ada program. We consider loosely coupled homogeneous systems in which the program/proceasor binding is specified within 
the distributed program (static binding). 

There have been a number of proposals for distributed programming languages, |l), (2), (3), (4), (5], |6|, |7j,lt [8) to name but a 
few. Most of language proposals have emphasised models for communication and synchronisation and/or a unified treatment 
of data abstmtions and multi-processing that are amenable to correctness proving. With few exceptions, eg. [7|, however, they 
have considered neither the real-time aspects of the languages nor the full problem space (see [9]) involved in distributed execution- 
Only a few of these languages likely to see widespread adoption and use, though the important principals they lay down are 
likely be adopted in future language designs. 

Ada, on the other hand, will see widespread use, and explicitly admits distributed execution. As yet, there have been only 
a few attempts at actually distributing its execution. Tedd, et. at (10), describe an approach that is based upon clustering 
resources into tightly coupled node* (shared bus) having digital communications among the nodes. They then Emit the language 
definition for inter-node operations (eg., no shared variable* on cross node references); they are currently in the process cf 
im plementin g their approach. CornhiO has introduced the notion of a separate partitioning language (11) that can be used to 
describe bow a program is to be partitioned after the program is written. (12| describes this language in greater detail. Agaia, 
neither of these approaches recognises the full problem space involved in the distributed execution of programs. (9) describes a 
number of dificuhies which both approaches most bee if they are to remain within the current Ada definition. 

|g| introduces three major dimensions to the problem of distributed program execution: the memory access architecture, 
the binding time, and the degree of homo g eneity. The range of distributed execution systems that can be represented by these 
' a larger than any of the distributed bn g"«t* efforts to date, including Ada, can address. For example, one of the 
major design decisions « k »‘ must be made in a distributed language is the units of the language that may be distributed. It is 
likely ,k »* one will want to the distributable unite a function of these dimen si on s. For ex a mp l e , one may want to allow 
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■lured wriiblw for wm» architectures sad disallow them for others. [lOj does this bjr disallowing shared sa ris b lso across nods 
boundaries. Yet the Ada Reference Manual is no* clear oa this point. There are also questions of to what extent the specification 
of distrihetioa should be part of the language (aa oppo e ed to being stated in a separate configuration pi s e e ); (9j dbcn ee r s these 
and several other issues. it is clear that the Ada language definition is realy not complete with respect to distributed execution. 

The work described in this paper is, thus, principally an rTprrinwatsi device to heip identify the beeic issnes and point 
toseard their solution. We restrict consideration to homogeneous loosely coupled computers with static binding specified within 
the program (one point in the problem space indent ified in j#j), and fellow the suggestion in (Oj and allow only Ebrary packages and 
subprograms to be distributed. We endeavor to avoid placing any further restrictions oa the language, and study the implications 
of effecting distributed execution within these constraints. This implies the need for remote screw to data objects, subprograms 
and tasks. 

Rather than write a complete Ada translator, see adopt a pretranslator approach in which we translate a distributed Ada 
program ( - in our system a distributed Ada program is a normal Ada p ro gra m with SITE pragmas iadrstiag where units are 
to be placed) into a set of normal Ada programs. We then use existing Ada compilers to translate each of the programs in the 
set. This approach has the dual goals of being a simpler experimental mechanism and utilising existing work where possible. It 
also has a few limitations, which will be pointed out in the remainder of the paper. 

The next section presents an overview of the approach. Section 3 then discusses the critical problems and the details of the 
approach taken. Section 4 analyses the project perfo r m ance of the method and section S summarises the current status of the 
work and discusses directions that must be explored in the future. 

a. OVERVIEW OF THE PROBLEM AND APPROACH 

The Problem 

We presume that the computers upon which a program is to be distributed are interconnected by s communication network, 
as shown in figure 1. Since we are allowing distribution of library packages and subprograms, our translation system must provide 
a means of accomplishing the following remote operations: 

• Access to procedures and functions declared in remote library units, 

• Reading and writing of data objects declared in remote library packages (and hence stored remotely), i.e., remotely shared 
data is allowed in our model, 

• Making [timed /conditional! entry calls on tasks declared in remote Ebrary packages, 

• Declaring/allocating (local) variables whose types are declared in remote library packages, 

• Elaborating tasks whose types are declared is remote library packages, 

• Managing task termination for tasks elaborated across machine boundaries. 

The approach 

The first issue that must be considered is the representation of the distribution. In our system, we write a single program 
and place a pragma called SITE before each library unit to specify the location on which that library unit is to reside. For 
example, consider a mobile space robot system consisting of several mobile vehicles (each with a robot mounted on it) and aa 
overall system controller. If it were desired to have one vehicle controlled by computer number 2 and the overall control using it 
(as well as several other similar systems) placed on computer 1, a sample of the relevant code would look as follows: 

pragma SITE (2); 
package VEHICLE is 
procedure MOVE(..); 


end VEHICLE; 


pragma SITE(l); 
with VEHICLE; 
procedure CONTROL h 


begin 


VEHICLEJdOVE(-); 


end CONTROL; 
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Fipn 2 ifttnlH the overall operatic* at oar system. A pre-translator traaaUtoa oor single Ada pnpw with SITE 
pratgxnae into a act of indepe nden t Ada pw p am i which inciada fibrary Modules of oar detip to effect cocnmenintion among 
processes. TW traaelatioa system weald replat* aB calls (within CONTROL) to Ike ptocodai* VEHICLE-MOVE^..) with ike 
appropriate naoU p ro c ed u re cal. Similarly aay refer en ces ia CONTROL to date objects or tank entries defined in package 
VEHICLE woald be translated into appropriate remote ref ers aces. E^ck of tke iadividaal programs can tkoa be compiled fay as 
»«iei«| Ada compiler. This approa ch simplifies the translation p ro ce s s co nsi derably since our pro- tra n sla tor is math leas complex 
than a fall Ada compiler. 

The remote operations and interprocess communication are menaced by a mt of iftsls created for unite that can be remotely 
referenced and an anderiying pr o cess to process mailbox system: During the pass through the pre- translator, all references to 
remote objects are replaced with appropriate t e fcrencea to spent*. Each program unit (for example, suppose it is unit A) which 
might b~ -enced from another, remote, unit (call it B) has three categories of agent associated with it. There is a local spent 
on the * hoi ling A, a remote spent on the site holding B (and every other site referencing A), and a pointer spent placed on 
the same sit' as the local agent. A is essentially unchanged by the pre-translator, and both the local and remote agents can be 
generated from only the specification of A. AB references within B to code or data objects in A are translated into appropriate 
calls to the remote agent of A (which resides on the same site ss B), which ia turn uses the message system to pass the service 
request to the local agent of A. The local agent perf o rms the necessary functions, returning any objects requested. The pointer 
agent serves to propagate object accesses involving access variables pointing to other sites, and is only required if such access 
variables are used. 

The relevant entities and Bow of data for the example above are shown in Figure 3. CONTROL-T is tke translation of 
CONTROL with the references to objects in VEHICLE replaced with calls into VEHICLE-REM-AGENT. 

S. TRANSLATION STRATEGY 

In order to solve the problems raised in the previous section the following issues must be resolved: 

• development of a general remote object accessing methodology, 

• translation of source code references to remote objects, 

• management of other remote service functions, e g., creating objects, and 

• generation of the agents. 

The solution to these problems, while leading to reasonably efficient code, involves a rather complex set of multiple pass operations 
and the generation and use of a number of auxiliary Sles of intermediate information. Thus, a set of utilities abo are needed to 
allow the user to perform these operations in a straightforward manner. 

By far the most complex of these issues is the development of a general remote object accessing method. This is complicated 
by the oeed to address arbitrarily nested record and array components and the fact that component pointers may point to 
logically nested records or arrays on other processors. We thus concentrate our discussion on matters relating to object access. 
The solution to most of the other issues follows the resolution of this problem in a reasonably straightforward manner. 

The structure of the agents is critical to solving this problem, and is generally in three parts: I) elements to access code 
objects, 2) elements to manage the address chain leading through qualified names of records and arrays, and 3) elements to 
manage other services. The interprocessor mail system and message structure is closely integrated with the ages t structure. 

We begin this section with a discussion of the overall agent structure and its use for accessing code objects, and then discuss 
related important issues of access via fully qualified names, the postal message structure, and the translation process. 

Agent Structure 

As mentioned in the previous section, three kinds of agents are generated whenever a library unit specification is encountered 
by the pretranslator: a local agent, a remote agent, and a pointer agent. Each agent is generated as a separate package, and 
assigned a unique name that is derived from the source package name. The agents can be generated simply from the package or 
subprogram specifications. 

The terms local and remote agent are used with respect to the processor holding the library unit which they represent. That 
is, the local agent resides on the same node as the unit it rep resents, while the remote agent resides at each other node refer- 
encing the unit. Thus, a remote action of some kind begins with the refe r encing unit making a call (after it is processed by the 
pre-translator) to the remote agent of the unit being accessed. For example, if the cell controller CONTROL makes a call to 
VEHlCLE..MOVE(..), the translated procedure CONTROL.T makes a call to the remote agent VEHICLE-REM-AGENT. We 
thus consider remote agents first. ’ «. 

Remote Afcnit 

Remote agents are merely collections of procedures and functions that effect remote calls. In the case of subprogram and 
task entry calls, they present an interface to the calling package identical to that of the original source package. In our previous 
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example, the package VEHICI.K REM.ACENT will contain a procedure MOVE(..) that will receive the call i nt en ded tor 
package VEHICLE. Theee procedures aad functions format aa a p prop ria te meant* record (deacribed below), aad dispatch it to 
the appropriate site via the postal servic e . When a ret ora value is rece ive d fans the local scant (oa the other p r o ces sor) via the 
postal service, this value will be reta r a ed to tbs cadSag snit. From tbs p er sp e ctiv e of tbs railing a ait, the facts that the actioa 
is remote aad that there are (at least) two agents in b etw ee n it aad lha called on it are transparent, except far tbe lodger time 
required. Time, we translation of subprogram or (simple) task calls a req ui red iu tbe calling unit, unless they gee arguments 
raiding remotely. 

Ia the case of remote data object re ference s, a trssspsrent iaterhee la not possible, last end , a act of procedures to get and 
put the values of remote objects of various types is generated. Again, theee procedures are generated from the specification of 
the Bbrmry package being ref er en ce d. Ia this case, the referencing unit (CONTROL ia our p revio us example) meet be translated 
to replace tbe object reference with a call to tbe appropriate get or put routine. Since tbe get and put routines can be overloaded 
(with respect to tbe specific argument types need) tbe translation is straightforward. Tbe specific arguments use d aad tbe detailed 
actions of tbe get and put routines are closely intertwined with the msnsgnntnt of fully qualified names, aad will be diacumed 
later. 

Two other points are worth mentioning. Since tbe structure of tbe remote sgent was chosen to m i n i mi n e tbe impact oa 
the referencing unit, tbe translation required by tbe pretranslator is a minimum. Also, since sending and receiving m emi giu 
from another processor is time consuming (relative to normal instruction processing times), the point after tbe transmission of a 
message is treated m a sychrooisatioo point so that other tasks may obtain tbe services of the epu while tbe reply to the message 
is in p rog re ss . 

Local Aftntt 

The local agents are tbe most complicated of the three agent types. Their task is to service requests from remote sites needing 
to access data objects, subprogra ms , or task entries. A local agent consists of N+2 tasks where N is the total number of functions, 
procedures, and task entries, contained in the source specification of the unit the agent is helping to represent. One of these tasks 
is associated with each of the aforementioned subprograms and task entries. 

One of the remaining two tasks is designated as tbe local agent main task. This task consists of a single loop that requests 
message records from the postal service (via a task entry call), interprets the request, and dispatches the request to the appro- 
priate handler (task or procedure) within the local sgent. Messages requesting access to data objects, are serviced immediately 
within the main task by calling a GETPUT procedure (described below) and an immediate reply is sent. 

with PACKAGE-NAME; package being represented 

task body AGENT-MAIN is 
M; MESSAGE-TYPE; 
begin 
loop 

POSTAL.MAIL-BOX.GET(M); - - get message 

case M OBJ-ENUM is - - Branch according to object name. 

- - Object references 

when NAME-1 => GETPUT(M, PACKAGE-NAME.NAME-1); 

when NAME-K => GETPUT(M, PACKAGE-NAMEJfAMEJC); 

- - Subprogram calls and task entries 

when NAME-X1 => MANAGER.DEPOSIT-NAMEJU(M); 

when NAME.X => MANAGERJ>EPOSIT-NAME_N(M); 

end case; 

SEND-RETURN(M); 

end loop; 

end AGENT-MAIN; 

Tbe above abstraction is only for a single distributed package. Actually, tbe message type would be embedded in a yet m ore 
general record having a varient part for each distributed package, and the actual code would be slightly mare involved. 

It is imperative that tbe main task not be blocked for it provides concurrent access to ail objects and types in the specification 
of the unit it represents, and if blocking occurred here, other, parallel, requests could be delayed. In particular, the agent mat 
not be blocked by a unit it calls on behalf of a remote client, as could occur if the agent directly called the unit (the sub p rogr a m 
called might, for instance, become blocked on an I/O wait). That is why a task is associated with each subprogram and tari 
entry. Tbe main task places the mere age r eceive d in a buffer, by calling an entry in a buffer manager task (tbe last of the task 
in the local agent). A flag counter corresponding to the requested call * also incremented at this time. 
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The hollar manager task kaa N aJfilkaial entries, whoaa acceptances art coniiitionsd on a positive value of cadi of the 
v rr rrr^i*! 1 "! N coasters (h&atiai that than is a me eng* to bo nttimd). There an N call manager tasks (tha N tasks 
c o rr e s pondin g to subprograms and task entries), whoso sob p or poaa k to rctriaea a maattga record from tha corresponding 
conditional task entry in tha buffer manager task, execute tha appropriate cal to tha aoorca package body, aad than ret am a 
reply to the remote sit*. 

The following code abstraction illustrates tha manager task aad tha tasks co rresponding to the subprograms and task entries 
that may be caled, 

task MANAGER in 

entry DEPOSIT JE1(MESG : in MESSAGE); 
entry DEPOSIT-SI (M ESC : In MESSAGE); 

entry EXTRACT-El(MESG : out MESSAGE); 
entry EXTRACT-SI (MESC : oat MESSAGE); 


and; 

task body MANAGER is 

E-FLAG: army {!.. MAX-ENTRIES) of INTEGER; 
begin 
loop 

select 

accept DEPOSIT Jil (MESC : in MESSAGE) do 
- - deposit the message for el 
E-FLAG(l) := ELFLAG(l) + 1; 

end; 


when E-FLAG(l) > 0 => 

accept EXTRACT -E1(MESG : oat MESSAGE) do 
- • extract a message from the buffer aad retain it 
E-FLAG(l) := E-FLAG(l) - 1 

end; 

end select; 
end loop; 
end MANAGER; 


The suffix El indi c a t e s the Ith entry point, and the suffix SI indicates the 1th subprogram. The structure of the entry task for 
entry El is as follows: 


task DO -El 
begin 
loop 

MANAGER.EXTRACT-El( ); 
El( ); 

- - send back message; 
end loop; 
end DO-El; 


The messages are provided by a mailbox system that de li ver s messages to the correct local agent. The message interpretation 
and task calls by the agent essentially achieves a routine to routine commu n ic ation between routines in the remote and local 
agents in a way that prevents delays in the r e s po n se to one request from locking out other parallel requests. 

Pointer spent* 

Our allowed model of distribution permits access variables to point to objects on machine* other than the one holding the 
access variable. Since access variables, as defined within a local Ada program, clearly cannot both the machine identity 
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ud an iddroi, whenever an access type definition is encountered in the source package, it is replaced by a record structure 
containing two fields: a site number, and the original access type. This new record type is then used in place of the access type. 
The site number is always checked against the current site number, to determine whether the object being painted to is on the 
local site, or an a remote site. 

Because access variables can be p amed from one machine to another, it is possible for a processor to bold an access variable 
pointing to an object on a site which it does not directly reference and for which it does not therefore have an agent. We therefore 
include pointer agents to allow access to objects on remote sites. The structure of pointer agents is similar to that of local agents, 
except that provision for subprogram calls need not be made. 


Remote Data Object Access 

Three characteristics of Ada data objects cause difficulty in developing a general mechanism for handling references to remote 
objects: 1) the objects may be composite objects, 2) they may have concatenated names, and 3) parts of a folly c onca ten a t ed 
name may be access variables pointing to objects on other machines. 

The first issue manifests itself when one must copy a composite object (as opposed to a component of the abject) from one 
site to another. For example, suppose that site 2 uses a record A on the right hand of an assignment statement and that A is 
located on site I. Eventually, the agent and message system must convert A to a bit string for transmission. It would usually 
be desireable that the part of the system that performs the conversion not be aware of the structure of the object (from object 
oriented design principles). However, if the object contains a memory address as part of its structure, the result received could 
be meaningless. For example, suppose the record A contains a variable length array, as shown below, 
subtype S is INTEGER range 1..MAX; 
type IA is array (INTEGER range <>) of INTEGER; 
type R(L: S := 1) is 
record 

B: IA(l.-L); 

C: INTEGER := 0; 
end record; 

A: R; 

One decision for the memory allocation for ...<: record might be to allocate the storage for the array from a heap and place only 
a pointer to the array (or possibly its dope vector) in the record. The need to perform whole object (record) assignments in 
Ada might discourage such a memory allocation scheme, but nevertheless, it is certainly a possibility. A bit by bit copy of the 
block of data corresponding to the record A, would then copy this address, which would have no usefulness when received by 
the requesting unit; in particular, the bit by bit copy of the record block would not result in the array values being transmitted. 
To avoid this problem, the routine that does the final message transmission must, indeed, contrary to the above assumption, 
have knowledge of the record structure so that the array values themselves may be transmitted, and not just the address of the 
array. Since we are describing a pre-translator approach that uses existing Ada compilers, this knowledge is dependent upon the 
implementation of the underlying compilers used. 

To see the second issue, suppose that site 2 contains a statement like X := A.C. How does one construct an address for A.C? 
Or describe, in a general way, to the agents what element is to be returned? The syntax “A.C” exists only on site 2, and the 
only information available there from the specification of the package containing A is the logical record structure of A, not its 
physical structure. Again, implementation dependent knowledge of the rules used for construction of the physical structure of 
records is necessary. 

If one were to now add a fourth component, D, to the type R above, that is an access type, and if the value of A.D were 
to point to another record stored on site 3, the third issue arises. The method used to calculate the address of the item to be 
retrieved must not only contain implementation dependent knowledge, but it must be distributed as well. 

Strategies for Remote Object Access 

We are studying two methods of obtaining composite (as well as scalar) objects: 1) using knowledge of the rules for storage 
allocation and physcial record and array construction, develop the distributed algorithms for calculating the address of the target 
object and then implement these, possibly in assembly or some other lower level language, and 2) use minimal implementation 
dependent knowledge and the logical structure of records and arrays to utilise standard Ada mechanisms to perform the object 
transfers. We expect the former to lead to more compact (in terms of code sixe) solutions, but to require a more detailed knowledge 
of the internal workings of the underlying compilers, while the latter will require less knowledge of the internal mechanisms used 
by the compilers at the expense of a larger amount of code (automatically generated, however) in the agents. Since the latter is 
also more in keeping with the philosophy of using existing compilers where possible with minimal knowledge of their internals, 
and since developing this approach will aid in developing the algorithms for the first approach, we have fol l owed this one first, 
and it is this one that will be described below. In subsequent w>>rk, we will explore the direct calculation of object addresses. 
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Access to remote objects is baaed upon the following things: 

• An enumerated type, TJ5NUM, whose values are the names of every type and field declared in the package for which an 
agent is being generated, and those in packages included via a with. 

• An enumerated type, N-ENUM, whose values are the names of every data object declared in the package for which an agent 
is being generated, and those in packages included via a with. 

• A collection of GETPUT procedures, one for each record or array type defined, whose functions are to either handle the 
request for an object reference if the request is for an object of the type the GETPUT handles, or to call another GETPUT 
if the object requested is, or is derived from, one of the fields of the type. 

• A variant message structure containing appropriate fields indicating the type of data required, the fields within records to 
be used, and an actual data object of the type being referenced. 

From the perspective of the local agent, a remote direct (not via access variables) data object access begins with the local 
agent main task receving a message from the postal system. One of the fields in this record contains a value of type N-ENUM 
that indicates the outermost name in the fully qualified name of the object being referenced. The local agent main task then 
performs a case statement on this value. There is thus a case for each object name. Each case calls a GETPUT procedure and 
passes it the message, the object named, and a count of the number of name components to the fully contatenated name sought 
(including array arguments). 

If the object passed is a scalar object, the count will be zero and the request can be satisfied dirvc ly by ‘he GETPUT * 
procedure by simply copying a value between the appropriate field in the message record and the object passed to it. Another 
field in the message record contains the type of the object to be returned. 

If the COUNT is not zero, then either an array element is being sought, or a fully concatenated name has not yet been fully 
expanded. In the former case, the indices for the array element (or slice) are contained in other fields of the message record and 
the GETPUT can select the appropriate element(s) of the array. These either directly satisfy the request or are used to recurse 
as described next. 

If the GETPUT is handling a record type, there will be another field in the message record corresponding to this type of 
record which will contain a value of type T-ENUM (containing the field name to be selected). The GETPUT contains a case 
statement conditioned on this field indicator. There is th-J a case corresponding to each field possible in the record. The action 
of each branch of the case is similar. Another GETPUT is called, passing to it the message record and object pointed to by a 
concatenation of the object name passed in and the corresponding field name. 

Below is an abstraction of a typical GETPUT routine for a record type. The forms for other types are similar, but tend to 
be even a bit simpler. 

procedure GETPUTJM: in out MESSAGE; OBJ: in out T; COUNT: NATURAL) is 
begin 

COUNT := COUNT - I; 

if COUNT = 0 then - - the name is fully expanded 

if <a get request > then 

- - copy value from OBJ to appropriate field in message record; 
else 

- - copy value from appropriate field in message record to OBJ; 
end if; 

return; 

end if; 

case < field name from message record> is 

when Fl => GETPUT(M, OBJ.Fl.COUNT); 

when FN => GETPUT(M, OBJ.FN.COUNT); 

end case: 
end; 


Here T is a record type of an object being passed in. and F1..FN are the fields in the record type. If one of the fields, FI. say, were 
an access variable, that access variable would have been replaced by a record (as described in the pointer agent section above) 
and the action for the corresponding case would first check to see if the requested object were on the current site or elsewhere. If 
local, then the call to GETPUT would be made as shown above. If elsewhere, then an appropriate message would be propagated 
to the pointer agent on the indicated site. 
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Menage Record Structure 

The mterproceaeor menage structure is key to the operation of the above object referencing s cheme . For each source package, 
a different message record type is defined. -These records consist of a fixed part and a variant part. There is one erne of the 
variant part for each type of data object defined in the source package. In the case of a subprogram or task entry call, the 
variant part of the record contains fields for all of the arguments, and if applicable, a function result. The fixed part of the record 
contains field selectors which are used for accessing fields of records, as described above. A simple example of a message record 
type is given below. It should be seffexplainatory from the previous discuss ion. 


type MESS.T( DATA.TYPE: TJBNUM ) la 
record 

OBJJDNUM : N-ENUM ; - - indicates outermost object 

TYPE1 .FIELD : T-ENUM; - - record type TYPE1 

TYPE2JC1 : TYPE2JC1.T; - - 2-dim array type TYPE2 
TYPE2JC2 : TYPE2JC2.T; 


case DATA-TYPE is - - reflects data to be exchanged 

when TYPE1-D => 

TYPEl-VAL : TYPEl; 
when TYPE2J) => 

TYPE2-VAL : TYPE2; 

when CALL1.D —> - - function CALLl 

CALLl-ARGl : FLOAT; 

CALLlJRESULT : FLOAT; 

when CALL2JD => - - subprogram CALL2 

CALL2-ARGI : INTEGER; 

CALL2-ARG2 : INTEGER; 
when FLOAT-D => 

FLOAT. VAL : FLOAT; 
when INTEGERJD => 

INTEGER. VAL : INTEGER; 
end case; 
end record; 
end; 


Since the postal service deals with all types of messages, a global message record type is defined. The global message record 
also consists of a fixed pari, and a variant part. The various cases of the variant part are, as one might guess, merely the different 
message records (or each source package. The fixed part contains the destination package number, and the return address, which 
consists of the source site number, and a logical channel number. 

Translation Procedure 

The translations required for the methods outlined above involve numerous steps and are quite involved. In this section we 
describe briefly the procedures to be used and a utility that haa been prepared to simplify use of the pre-translator. 

The first step in the translation procedure is to insure that the program to be distributed is correct. This is accomplished by 
compiling it for a single system. The programmer must do this before invoking the pre-translator. 

When a correct program is available, the translation and compilation procedure consists of the following steps: 1) determina- 
tion of the order of pretranslation of source files, 2) pretranslation of source files, 3) pre-link operations, 4) determination of the 
order of compilation of original sources (including agents) for target sites, S) compiling snd linking of individual site programs. 
Two utilities have been written to facilitate some of these steps. 

The pre-compilation utility (ADAUTIL) will translate the network of package dependencies implicit in a set of source files to 
a set of file dependencies in Unix “makefile’ format. The list of relevant source files must be specified, and one or more targets 
(main programs) must be specified. Since the order of pretranslation is identical to the order of Ada compilation, ADAUTIL 
takes an option specifying whether a makefile to run the pretranslator, or a makefile to run the Ada compiler is desired. 

The second utility, called MESSUT1L, performs step three above. The operations done during setp 3 are: l) constructing 
the global message record from all relevant package message records, 2) constructing a package of package site constants, 3) 
constructing main procedures for each site, and 4) constructing a meta makefile capable of performing steps 4 and $ above, 
ff Two scripts were written to simplify the pretranslation process. One script performs slops 1 to 3 above, and the other invokes 

the meta makefile to perform steps 4 and 5. If any non-Ada object modules need to be linked into any site, the meta makefile 
may be edited in between the running of the two scripts. 
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4 . DISCUSSION OF THE APPROACH 


One of our principal concerns with the system developed is the run-time overhead associated with the mechanisms we used. 
We can model this performance in terms of the run-time overhead associated with various kinds of remote references. Frans 
the tests performed in [13[ we know that task rendezvous times exceed procedure call times by one and a half to two orders of 
magnitude, and that task elaboration times are several times larger than rendezvous times. We can also reasonably expert the 
network communications times to be sizable. For example message end-to-end times for MAP are on the order of 100ms, more or 
less independent of message size [14], for the Intel hypercube, a few milliseconds, and for the NCUBE hypercube, several hundred 
microseconds to a millisecond, where the latter two depend somewhat upon message size, the variable component of messsge star 
being 1-10 mkroseconds/byte [15j. We thus neglect all local procedure and function call times, and model our overhead in tern* 
of the number of messages and rendezvous required. 

Thus, let t m and t, be the times to complete a message transfer and local rendezvous, respectively and let and n‘ be 
the number of messages and local rendezvous required for a remote operation or type o. Then, the time to complete a remote 
operation is 

n m ' Tm + n* • l r 

In these cases, we represent the overhead by the pair (n^.nj). 

Whenever there are task elaborations involved, we represent the number by E. It is listed separately since it is generally not 
necessary to do the task elaboration with each access, but only when tasks or procedures are first elaborated. Nevertheless, even 
though many of these need be done only once immediately after system load, the number of tasks in the system could have 
impact on the scheduling algorithms to be used and the efficiency or any runtime system, and the number E is thus important 

The following sections present briefly the costs associated with each of the remote operations. 

Data Objects — (2,4), E = 0 

Access/Updates to data objects require two messages and four rendezvous. One message is to send the request and the motu. 
to receive an acknowledgement. The rendezvous are for the mail system. This presumes that the requested object is on the first 
remote site accessed. If there is a continuation to other sites through pointers, the above numbers must be mulitpiird by the 
number of remote accesses required to satisfy the request. 

Task Objects — (2, 6), E = # of entries 

Task objects are accessed through entry calls. This requires two messages as for data objects and six rendezvous for synchro- 
nization (4 for the mail system and 2 for the handler). 

The number of task elaborations that need to be done initially is equal to the number of entries to the task. Entry calk to 
task objects created from task types require no special handling by themselves. However, each task object created from a remote 
type require' two messages for creation and four rendezvous for synchronization. All further access are as in the case of task 
objects. 

Procedures and Functions — (2, 6); E = l 

Since the local agent treats procedure and function calls in the same way as task entry calls, the analysis U analogous. 
Pointers 

There are two factors to consider here, the overhead when the object pointed to is remote, and the overhead when the object 
is local. Remember that all pointers are replaced with records having a site number and a pointer. This requires that all accesses 
via pointers begin with a check of whether or not the object is local or remote. If remote, the time of the check will be insignificant 
in comparison to the time required for the remote access and may be neglected. In this case the overhead depends upon the type 
of objected being referenced, and will follow the results obtained above. 

However, if the access is local, the overhead is more significant The exact amount of degradation will depend upon how 
an individual compiler implements pointer accesses and if then else constructs. In a simple test in which we wrote as efficient 
assembly language code as we could for local pointer accesses with and without the pointer record construct used here, the 
difference was a factor of four. In interpreting this, however, one must take into account the magnitude of time involved (only 
a few microseconds are the most) and the frequency of occurence. With these considerations taken into account, we do not feet 
that much overall lime will be added to local accesses. 

Summary Analysis Comments 

To place the above analyses in perspective, one must compare typical times for message transfers and rendezvous. Sonic 
typical network times were mentioned above. Rendezvous times on the order of 500-600 microseconds have been reported for an 
8 mHz IBM PC/AT. and on the order of 300-400 microseconds for Motorola 68000 processor. It is tlso the case that these tm*r» 
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have been dropping significantly .-'ith o«vJi ne- release oi' Ada compilers intended for real-time applications, and are predicted 
by Ada vendors tc become ye< considerably smaller over the real year or two. Thus, except for the fastest networks, the message 
times will either be close to the rendezvous times or dominate them, and the approach taken will be primarily influenced b> the 
network message limr*. 

There is further issue that may be of concern, the number of tasks and GET PUT routines needed in the local agents. These 
have a linear dependence upon the number of entries (and subprograms) and types present in a remotely acct ed package. While 
this may seem rather large, one is not likely to access a large number of things remotely, and those that are accessed remotely 
can be packaged separately from those that are not, thus keeping tire number of extra tasks and routines to a minimum. 

5. STATUS AND CONCLUSIONS 

At the present time, the distributed translation system is operational for distributed packages with simple objects in their 
visible parts, i.e , no record or array definitions. Scalar data objects, subprograms and declared tasks may be directly referenced 
(no timed or contkmal calls). Tests have bti.’i successfully completed with up to three VAX processors cooperating on the 
execution of a single program. The implementation of the strategy described for referencing arrays and records (with fully 
concatenated names) is nearly complete, and expected to be in operation within a few weeks. 

Nevertheless, there is still considerable work to be accomplished before the distribution of library' packages and subprograms 
is complete. Although the strategy has been determined (see [ 16|) , work has not yet been begun on handling timed/conditional 
task entry calls. Similarly, the dynamic creation of tasks is not complete. Two strategies will be implemented in this case. In 
the first, the created objects will be placed on the site elaborating the definition of the task type. In the second, the task object 
will be placed on the site creating the task through a declaration or new operator. The first is simpler to implement, but may 
make the task objects remote from the unit executing the code calling for their creation, while the second implementation is 
considerably more complex, and as noted in 9 , may contain hidden remote object references. Finally, task termination must be 
properly handled. 

More importantly, there are many issues of language definition that must be addressed. Our work has only addressed one 
point in the problem space to date, homogeneous, loosely coupled systems with static distribution. Additional representation 
mechanisms are needed to describe limitations dependent upon architectural considerations, to describe binding mechanisms, 
and to describe processor types (so that implicit data conversions can be accomplished). Moreover, it is probably necessary to 
require greater use of representational specifications on data objects to which remote access is allowed. Finally, there should be 
a more explicit definition of the allowed units of distribution. 
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Figure 1: Loosely coupled system upon which we seek distributed program execution 




Figure 2: Overall operation of translation system 
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Figure 3: Structure of translated example program 













